This invention is in the field of the test and configuration of large scale integrated circuits. Embodiments are more specifically directed to an architecture for invoking redundant memory elements.
Many modern electronic integrated circuits integrate essentially all necessary functional components of a computer system, whether general purpose or arranged for a particular end application. Those large scale integrated circuits that include the computational capability for controlling and managing a wide range of functions and useful applications are often referred to as “system on a chip”, or “SoC”, devices. Typical modern SoC architectures include one or more processor cores that carry out the digital computer functions of retrieving executable instructions from memory, performing arithmetic and logical operations on digital data retrieved from memory, and storing the results of those operations in memory. Other digital, analog, mixed-signal, or even RF functions may also be integrated into the SoC for acquiring and outputting the data processed by the processor cores. In any case, considering the large amount of digital data often involved in performing the complex functions of these modern devices, significant solid-state memory capacity, including both volatile and non-volatile memory, is now commonly implemented in these SoC devices.
To optimize performance, memory resources are typically distributed throughout the typical modern SoC device. This distributed memory architecture results in memory resources being physically (or logically) proximate to the processing function that will be accessing it. For example, the deployment of local memory resources will minimize the traffic over the system bus, which reduces the likelihood of bus contention and undesirable latency, and also reduces access time and memory management overhead. In many instances, these embedded memories are not accessible over the system bus, but are only available to the processor circuitry in which it is realized.
As known in the art, SoC devices typically include internal test circuitry (“built-in self-test”, or “BIST”, circuitry) that executes a self-test operation for the device upon power-up or reset. BIST may also be involved in the testing of memory, both at the time of manufacture and also on power-up, and is especially useful for testing those embedded memories that are not accessible over the system buses of the SoC device. Some conventional BIST memory test techniques include the placement of hardwired logic in the SoC, by way of which memory test algorithms developed at the time of circuit design are implemented; however, it may not be feasible to determine the particular tests to be performed at that early stage of the process. Programmable BIST (“pBIST”) techniques have been developed to test embedded memories in the SoC context. For example, the SoC may include a general purpose test controller that is programmed by a set of instructions to produce test conditions for the various internal and embedded functions of the device, and to receive and log the responses of those functions to those test conditions. In the memory test context, these operations include the writing of the desired data pattern to an embedded memory, and then addressing the memory to retrieve and compare the stored data to the expected data. Typically, the BIST data path over which the data are communicated during memory test is a separate and independent data path from that by which the embedded memories are accessed in normal operation of the SoC.
In many of these modern SoC devices, embedded memory resources occupy the majority of the chip area of the SoC device, in some cases as much as 70% of the total chip area. Because of this predominance of the overall chip area, manufacturers will tend to use the most advanced transistor technology, and thus the minimum available feature sizes, in the memory arrays of the SoC device. As known in the art, the smaller the feature size of a transistor, the smaller is the size of a “killing” defect that can cause its failure. Accordingly, a large portion of the chip area in the SoC will also be the most vulnerable to manufacturing defects.
Accordingly, most memory arrays in modern large scale integrated circuits include some type of redundancy. In general, memory redundancy allows the replacement of failed memory cells with spare memory cells, typically by reconfiguring the address decoding circuitry for the array. For example, a memory array may be constructed to have one or more “repair entities”, such as one or more spare rows, one or more spare columns, or some combination of spare rows and columns. These spare memory cells will not be involved in the storing of data if all of the main memory cells are properly functioning, but are available to be mapped into the memory address space in place of failed cells in the main memory array.
In the embedded memory context, built-in self-repair (BISR) capability has become common in many modern large scale integrated circuits. In a general sense, BISR circuitry constitutes an interface between the BIST data path and the redundancy logic, in that it determines whether repair is necessary based on the results of the BIST routines, and if so, determines the mapping of the repair entities in place of the failed cells. In this regard, the BISR circuitry of an integrated circuit typically includes built-in repair analysis (BIRA) logic that receives the failure information for each repairable memory from the BIST circuitry, and that allocates the repair entities for those memories, typically according to a redundancy analysis algorithm. The redundancy allocation is then forwarded to fuse controller circuitry, for configuration of the “fuses” according to the allocation.
Various types of “fuses” may be used to configure the memory redundancy based on the BIST and other test results. According to “hard” repair techniques, permanent fuses (e.g., laser-blown or electrically-blown metal or semiconductor fuses) or one-time-programmable (OTP) non-volatile memory cells are blown or programmed, as the case may be, to permanently store the redundancy repair information in a type of read-only memory (i.e., the “fuse ROM”). For “soft” redundancy repair, the redundancy “fuses” are banks of flip-flops that are loaded with the reconfiguration information based on the desired allocation. Of course, these flip-flops must be loaded each time that the SoC is powered up. In “firm” repair, electrically erasable non-volatile memory cells store the reconfiguration information, but can be erased if it becomes necessary to reconfigure the repair entities. Given these techniques, hard repair is best-suited for configuring memory redundancy at manufacturing test, but generally cannot be invoked for repairing later-life failed bits. Conversely, soft repair can be used at the time of manufacture and also over the device life, but requires complete testing of the memories, and repeating of the memory test following the loading of the repair configuration, each time that the device is powered up. Hybrid schemes are also known, in which both hard and soft repair is applied, with the hard repair performed at manufacturing test and the soft repair used during later life of the device. For example, at manufacturing test, soft repair information acquired via BISR analysis may be used to set the state of hard repair fuses. These repairs will be transparent in subsequent BIST/BISR each time the device is powered up, with soft repair applied to only the additional memory cells that fail over the operating life of the device.
Continuing improvements in manufacturing technology have enabled the implementation of a wide number and variety of functional units into a single SoC. These functional units are often in the form of a block of programmable or custom logic circuitry, along with embedded memory resources, that is “portable” in the sense that it can be placed in an integrated circuit layout as a whole in order to provide the desired function. These blocks are referred to in the art as processor cores or “intellectual property cores” (or “IPs”, for short). It is now not uncommon for multiple processor cores from different vendors and of different functional and BIST architectures to reside within the same large scale integrated circuit. In such modern large-scale SoC devices, the number of memory arrays that are embedded in these processor cores can be quite large, numbering into the hundreds in some cases. One example of a current-day SoC has nineteen processor cores (which included embedded memory) of seven different functional types, from three different sources and thus three different BIST datapath architectures, along with additional peripheral functional units that also include embedded memories. The embedded memory instances can themselves be quite diverse among themselves, with different data word widths, varying redundancy capability, widely different operating frequencies (e.g., from less than 100 MHz to greater than 1 GHz), and differing cell technology. This diversity in embedded memory type and BIST datapath architecture greatly complicates the implementation of BISR to maximize manufacturing yield and maintain reliability of the overall device.
Those SoC devices that include processor cores from different sources or vendors complicate the BISR task. Some vendors of processor core IPs embed BIST circuitry and a BIST datapath entirely within the IP, such that communication with embedded memories in that IP can only be accessed over the functional datapath; no external access to the BIST datapath is provided. However, memory controller functions within these “black box” processor core IPs apply banking and other logical address translation to the embedded memories, such that full control of the addressing and operation of the embedded memories is not available to BIST and BISR circuitry outside of those IPs. In some conventional SoC implementations, BISR is simply not available for memories embedded in these black box processor cores.
Conventional electronic design automation (EDA) solutions apply a brute force approach to implementing BIST/BISR for devices including such IP source diversity. Specifically, these EDA implementations provide dedicated memory test, repair analysis, and repair allocation circuitry for each and every embedded BIST DP processor core interface. The chip area required under this approach can be quite substantial, and thus costly to implement in terms of silicon real estate.
FIG. 1 illustrates a generalized BIST/BISR architecture according to a conventional EDA approach for applying BISR to embedded memory instances of different type within the same processor core IP. In this conventional example, processor core 2 includes embedded memories M1, M2, M3, each of which is accessible to the logic circuitry (not shown) within processor core 2 itself but is not directly accessible from outside of processor core 2. In this example, embedded memories M1, M2, M3 are testable over embedded BIST datapath 4 within processor core 2. The contents of memories M1, M2, M3 resulting from these BIST operations are accessible to circuitry outside of processor core 2 only by way of BIST datapath 4, which is typically at an interface over which processor core 2 communicates its BIST data for resolution by external test circuitry (e.g., external test equipment, BISR circuitry in the embedding integrated circuit, etc.). However, these BIST data are typically encoded and arranged logically according to the bit line architecture of the particular embedded memories, and to the memory banking and logical memory address mapping applied by memory controller functions in processor core 2 (and thus not necessarily visible from outside the IP), rather than physically. As such, these memory data must be decoded and remapped, logically to physically, in order to analyze the failing locations for assignment of redundant repair entities to those failing locations.
According to this conventional EDA architecture, data from each of memories M1, M2, M3 are decoded by an instance of output decode circuitry 8 for memory. In this example, the three memories M1, M2, M3 are each associated with a corresponding instance of multiplexed mapping logic 61, 62, 63 that decodes the BIST data presented by over embedded BIST datapath 4 into a form suitable for analyzing and applying redundancy repair, according to the corresponding data organization, bit line architecture, physical to logical address mapping, banking arrangement, etc. The logical data word width will typically vary among the constituent memories M1, M2, M3; BIST datapath 4 will thus have a logical width to accommodate the widest memory data path. Referring to the output decode instance for memory M1, AND function 51 gates the application of the BIST data from embedded BIST datapath 4 to the corresponding multiplexed mapping logic 61, in response to an identifier signal M1 indicating that memory M1 is the currently-tested memory with its BIST data presented by embedded BIST datapath 4. Multiplexed mapping logic 61 decodes, or maps, these BIST data for memory M1 into the appropriate logical order or format for BISR analysis, and presents that data (of a word width w1 as shown in FIG. 1) to BISR circuitry 8 to determine whether redundancy repair is necessary and, if so, the allocation of repair resources to best address the failed bits. Similarly, memories M2, M3 are each associated with respective instances of this output decode circuitry of AND function 52, 53 and multiplexed mapping logic 62, 63, with the results presented to BISR circuitry 8.
BISR circuitry 8 includes dedicated circuitry for each of memories M1, M2, M3 according to this conventional EDA BIST architecture, as shown in FIG. 1. Referring again to the data path for memory M1, the remapped BIST data presented by multiplexed mapping logic 61 are compared by XOR function 71 with the expected BIST data M1_ED for the corresponding (mapped) addresses and test being performed, to produce fail signature FD1 indicating those bit locations, if any, that failed the BIST routine (i.e., produced data differing from expected data M1_ED). This fail signature FD1 is presented to fuse encode logic 101, which performs built-in repair analysis (BIRA) to determine whether redundancy repair is necessary and, if so, allocates the repair entities available at memory M1 to address those bit failures, and encodes the fuse pattern appropriate to invoke that allocation. The fuse encoding produced by fuse encode logic 101 is then applied to shadow fuse registers 121, which are typically flip-flops that contain the “soft” redundancy information (i.e., repair mapping) to be used in the accessing of memory M1. If “firm” or “hard” repair is to be implemented, the contents of shadow fuse registers 121 are applied to the appropriate fuse programming circuitry for programming into the fuse ROM for memory M1. Again, each of the other memories M2, M3 are provided with their own dedicated instances of BISR circuitry 8 according to this conventional architecture, each such instance including a corresponding XOR function 7x, fuse encode logic 1x, and shadow fuse registers 12x.
While this conventional EDA architecture is capable of implementing BISR for embedded memories of various architectures, each embedded memory is provided with its own dedicated BISR circuitry for performing the redundancy repair analysis from the fail signature of that memory and for encoding the fuse pattern because of variations among the architectures of those memories. Especially in SoC devices with diverse processor cores (i.e., some including embedded BIST circuitry), this approach is very area intensive, and thus costly to implement in modern large scale integrated circuits. Considering that many modern SoC devices include hundreds of embedded memories, the chip area overhead necessary for self-test and self-repair logic can be massive, in some cases requiring as many as one million logic gates. This overhead will appear especially costly for mature devices, since the utilization of the available fuses in the fuse ROM will be relatively low for high-yield devices, yet the BISR circuitry must yet be present.